Part IV - Chapter 15

1. In what ways can the risk management plan provide an approach for performing risk management cost-effectively?

• A risk management plan incorporates the documented goals, strategy, and methods for performing risk management on a project. The purpose of developing such a plan is to determine the approach for performing risk management cost-effectively on the project. The plan should be long enough to convey this information to project participants. For a small project, the risk management plan might be only five pages long. For a large project, the plan might grow to 20 pages. The plan may be separated document or part of a larger plan.

2. Discuss the advantages and disadvantages of a proactive approach to managing risk.

• A proactive approach to a risk management plan should be documented in an easily understood format. It should be approved through the appropriate management to promote support and commitment, then be distributed to the project team to provide common goals, strategy, and methods for performing risk management. The plan should be maintained with a revision history that includes version number, date, and description of change.

• While the above approach is a good one to take, there are times where it is difficult to implement. Projects that spring up at a moment’s notice and are deemed critical may not have the luxury of this type of through planning. Risk management will most likely be involved but maintaining a change history document is difficult when you are in a time pressure environment. Quick turn-around projects will also have documentation created but may not be coordinated as thoroughly as you normally would.

3. List five responsibilities associated with the role of project manager. For each responsibility, provide a risk that might occur. Identify the associated interfaces for communication regarding each risk.

4. List five responsibilities associated with the role of quality manager. For each responsibility, provide a risk that might occur. Identify the associated interface for communication regarding each risk.

5. List five responsibilities associated with the role of system engineer. For each responsibility, provide a risk that might occur. Identify the associated interface for communication regarding each risk.

6. List five responsibilities associated with the role of software engineer. For each responsibility, provide a risk that might occur. Identify the associated interface for communication regarding each risk.

7. Do you think the separation of process and plan enables flexibility for change? Discuss why you do or do not think so.

• The risk management process is a systematic and structures way to manage risks that includes the activities and mechanisms used to transform project knowledge into decision-making information. The risk management plan can point to a documented risk management process. Whether by hard copy reference or soft copy linkage, the separation of process and plan enables the flexibility for change. You can define the risk management process by tailoring a standard risk management process.

8. Discuss the advantages and disadvantages of an independent quality audit of the risk management practices to ensure adherence to the risk management plan.

• The true advantages of the independent quality audit are that the people performing the review are not involved in the process and have a completely objective view of the project. They can identify things that project members don’t realize are a problem. For example, they can identify an area that has been brushed over by team members because they feel that the subject should be understood by all. By leaving out key elements based upon an assumption can cause severe problems later down the road where a part of the team doesn’t know what they were assumed they did.

• Disadvantages are usually a fiscal one, the cost of having an independent reviewer perform the review. Another issue is the quality of work the reviewer does; they could be a new company and have a limited amount of experience. They could also not understand the true scope of the project and give management poor advice and make the project head in a direction of failure.

9. Discuss the difference between the goal of minimizing risk and the goal of maximizing opportunity.

• The whole process of risk management is a delicate balance of how much effort you want to put in. By analyzing every possibility of risk and trying to manage every aspect of the analysis the team will come to a screeching halt in progress. On the other side, if not enough attention is given to key parts of the project then you can run the risk of having a product that fails to meet the desired outcome.

• There is a fine balance in the entire process. The scope of the project should be the deciding factor on which direction to lean towards. Building a critical system you would want to minimize the risk as the objective, where if you are developing an e-commerce type of system the goal would be to maximize opportunity.

10. Do you agree that success or failure is often determined on the drawing board? Discuss why you do or do not agree.

• I truly believe that the success or failure of a project is determined on the drawing board. I give the current project at work as a prime example. The design phase of the project was thought as a simple conversion process and that the existing desktop application code could be simply transferred to a web implementation. Each process of the application to be transferred was flow charted out and given a very high level description. None of the tables were scrutinized and simply crossed over.

• The result was a complete mess. Each developed was tasked to review the flow chart, then review the application source code and then write an appropriate duplication. As we found out in the early stages it was difficult to dissect the code from the previous application because it was written in an environment no one was familiar with. It became increasingly difficult for each developer to dissect a part of the program with any success.

• It was apparent that we had to change gears and have the primary developer create detailed outlines that addresses functionality, tables, and desired output for the major processes. Once this was done the progress of the project started to increase. The problem the project now has is waiting for the outlines to be written.

• The lesson learned was not having a detailed design to start with. If that was completed in the first place we could have reviewed the major processes and identified similar processes and designed functions to handle these activities. We could have looked at the table structure and made decisions on data types and normalization issues. Of course this is easy to see at the later stages of the project, but that is the whole point of a detailed design.

Project Home Next Section